According to Third Generation Partnership Project (3GPP) Technical Specification (TS) 33.203 V1.0.0 (Access Security for IP-based Services), the IMS (i.e. Internet Protocol (IP) Multimedia Core Network Subsystem or IP Multimedia Subsystem) in UMTS (Universal Mobile Telecommunications System) supports IP Multimedia applications such as conferencing using audio, video, and multimedia. 3GPP has chosen Session Initiation Protocol (SIP) as the signaling protocol for creating and terminating Multimedia sessions for wireless terminals, including mobile phones, laptop computers with a WLAN (wireless local area network) card and a USIM/ISIN (UMTS Subscriber Identity Nodule/IP Multimedia Private Identity), and other kinds of UE (user equipment). TS 33.203 sets out how a subscriber to IMS services is authenticated and how a subscriber authenticates the IMS, according to what is called IMS Authentication and Key Agreement (IMS AKA), which is patterned after the UMTS AKA set out in TS 33.102. (Every operator and even third parties can provide IMS services; thus not only is it necessary to authenticate that a user (i.e. the UE) is a subscriber, but it is also necessary to authenticate that the entity providing IMS services to the user is who it claims to be.)
Authentication allows each party to a communication to trust that the other is who it purports to be. Having such trust is necessary for the communicating parties to encrypt messages for each other and to rely on a digital signature purportedly provided by the other. In case of encryption, for example, when sending a message, the parties to a communication must each rely on their having a key appropriate for the receiving party and not a key that would allow an eavesdropper to decrypt the message. A set of protocols, procedures, and associated agreements that allow communicating entities to trust that each is who it purports to be, so that keys that are used for digital signatures and encryption are genuine, is called a trust infrastructure.
All trust infrastructures ultimately rely on some information being provided “out-of-band,” i.e. on some transaction not susceptible to the eavesdropping that might occur in a communication using the trust infrastructure. The out-of-band information is typically (if not always) a (public) key or keys associated with an identity (of the owner of the key). For enabling a UTRAN (UMTS Terrestrial Radio Access Network) to authenticate a user and vice versa, UMTS AKA relies on a private key associated with the user, i.e. associated with the UMTS Subscriber Identity Module (USIM) in the UE operated by the user. The key is provided out-of-band to the USIM in the UE and is also provided out-of-band to a so-called authorization center (AuC), a facility that is part of the home environment for the user. The identity to be associated with the key is of course provided along with the key, but authentication does not rely on keeping secret the identity associated with the private key.
Similarly, IMS AKA, in providing a trust infrastructure for accessing IM services via a mobile phone, uses a private key exchanged out-of-band between an ISIM (IM Services Identity Module, playing a role analogous to that played by the USIM for general UMTS services) and an IM authorization center; the key is associated with an IP Multimedia Private Identity (IMPI) provided by the manufacturer of the mobile phone and stored in the ISIM.
Outside of the context of accessing IM services, authentication is sometimes performed using what is called a Public Key Infrastructure (PKI) as the trust infrastructure. A PKI makes use of what are called certification authorities (CAs) to issue so-called digital Certificates; because the Certificates are issued by a CA out-of-band to entities seeking to enable others to authenticate them, it is these digital certificates that are the out-of-band component of the trust infrastructure provided by PKI. Such Certificates provide for the secure distribution of Public Keys (for use in asymmetric key encryption), which in effect authenticates the participants in a communication (since the corresponding private keys can be used to digitally sign documents), i.e. the process of securely obtaining the public key of an entity is tantamount to authenticating the entity. Like almost all (if not all) out-of-band information serving as the basis for trust, a Certificate is a structured document that binds the name of a participant in a communication (or similar information) to a public key (the participant's public key), and is digitally signed by a trusted third party called a Certification Authority or CA. To verify a certificate, the user of the public key (sometimes called the relying party) must first obtain the public key of the CA by some other (out-of-band) trusted means. If this is done, then if the CA is able to certify the public key of other CAs, which can in turn certify other CAs and so on, then an entity relying on the (trusted) CA will be able to securely communicate with any other entity for which there is a chain of certificates between the trusted CA and the CA certifying the key of the other entity.
A PKI includes not only a sufficiently interlinked network of CAs to ensure that any relying party can verify any given certificate, but also systems to issue and store certificates, to determine their authenticity, and to revoke certificates if keys become compromised, as well as possibly other services in connection with effectively utilizing public key cryptography and digital signatures, such as a non-repudiation service and a digital notary or digital time-stamping service. All of these services must work together and have a common understanding of the formats and protocols necessary to achieve their aims. It is the collection of these components that has come to be known as a PKI.
As set out in The Internet Key Exchange (IKE), RFC 2409 of the Network Working Group, the IKE protocol is a hybrid protocol for providing authenticated keying material for security associations in a protected manner, or in other words, for enabling each party in a communication between two parties to authenticate the other and then provide keying material with confidence that the keying material is associated with the intended party and not some imposter. Processes which implement the IKE protocol can be used for negotiating virtual private networks (VPNs) and also for providing a remote user from a remote site (whose IP address need not be known beforehand) access to a secure host or network.
The IKE protocol supports initiator negotiation, i.e. the protocol can be used in so-called initiator mode. Initiator mode is where the negotiating parties are not the endpoints for which security association negotiation is taking place. When used in initiator mode, the identities of the end parties remain hidden.
IKE presents different exchanges as modes which operate in one of two phases. Phase 1 is where the ISAKMP (Internet Security Association Key Management Protocol) peers (in the communication between the two parties) establish a secure, authenticated channel by which to communicate. This is called the ISAKMP Security Association (SA). IKE then provides a so-called Main Mode (for first beginning a communication session) and a so-called Aggressive Mode (to restart a communication session after the session is terminated because of there having been no activity for a predetermined time, for example), each accomplishing a phase 1 exchange. Phase 2 is where Security Associations are negotiated on behalf of services such as IPsec or any other service which needs key material and/or parameter negotiation. A so-called Quick Mode accomplishes a phase 2 exchange.
Section 5 of RFC 2409 provides several different kinds of phase 1 authentications, such as authentication with digital signatures (section 5.1) and also authentication with public key encryption (section 5.2). Authentication with public key encryption relies on there being a PKI trust infrastructure in place. Because a large-scale PKI has yet to be implemented, and because of the complexity of such an infrastructure, it would be advantageous to have available for use an additional phase 1 authentication, similar to the authentication with public key encryption, but relying on a trust infrastructure that has already been implemented.